home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Sep 89 / Y0030-Problem with Assert-Sep89 < prev    next >
Encoding:
Text File  |  1989-09-08  |  1.6 KB  |  52 lines  |  [TEXT/GEOL]
  1. Item    9225073                         8-Sept-89        00:40
  2.  
  3. From:   D1157                           All Star Computer, L Goldman,PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Problem with Assertion
  8.  
  9. Dear MacAppers:
  10.  
  11. Re: Assertion:
  12.  
  13. I like this routine. I sprinkle them at key places in my code to serve as
  14. "reality-checks".
  15.  
  16. But it has a serious bug: Failure should be _always_ be called at the
  17. end of the routine. In that case, the program with debugging will function
  18. just like the non-debug version.
  19.  
  20. As it stands in ß9, if I forget what I'm doing and just type 'G' in response to
  21. the Assertion failure, the program will proceed _in_spite_of_ the Assertion. If
  22. DebugStr is called, the program is _sure_ to die, because there is no way to
  23. signal failure from my debugger (TMON).
  24.  
  25. Here's a better version:
  26.  
  27. PROCEDURE Assertion(condition: Boolean; description: StringPtr);
  28.    BEGIN
  29.        IF NOT condition THEN
  30.            BEGIN
  31.            {$IFC qDebug}
  32.            GetCallersMethodName(pWho);
  33.            IF CanWriteLn THEN
  34.                BEGIN
  35.                WriteLn(Concat('Assertion failed in ', pWho, ': ', description^)
  36.                EnterMacAppDebugger;
  37.                END
  38.            ELSE
  39.                DebugStr(Concat('Assertion failed in ', pWho, ': ', description^
  40.            {$EndC}  {ƒƒƒ changed this line}
  41.            Failure(minErr, 0); { ??? need to assign a message }
  42.            {ƒƒƒ $EndC  Remove this line}
  43.            END;
  44.    END;
  45.  
  46. Further, I don't believe any non-zero message need be passed to Failure,
  47. because it is the responsibility of Failure handlers to update the message if
  48. they prefer.
  49.  
  50. Larry Goldman
  51.  
  52.